1. Field of the Invention
Aspects of the present invention relate to computer systems. More particularly, aspects of the present invention relate to testing of computer systems.
2. Description of Related Art
Computer system developers desire to release bug-free systems and/or applications. Be it hardware, software, or firmware, all computer products undergo some level of testing. Conventional testing systems allow test operators to specify a fault to occur and allow a system to encounter a fault. Often, identical processes may slightly differ in their execution based on environmental conditions. These alterations of the processes complicate testing procedures in that testing systems lack repeatability once a system error caused by the fault has been encountered.
FIG. 2 shows an example of a conventional testing process. In step 201, a user sets high-level testing conditions for a test to be run including a selection of a fault to occur. In step 202, a test is run. In step 203, the system reports a fault if, for example, a process attempted to access X, where X is a memory or an attempt to write or read from a drive, and the like. In step 204, the system monitors the results and reports and error if the system did not handle the fault properly. In general, conventional testing systems monitor application programming interface interactions and change return values according to a fault being created. Here, these systems allow a user to specify a percentage chance that a fault may occur (e.g., 90% of a memory fault to occur). The purpose of specifying the percentage fault is to allow some faults to occur later, thereby identifying processes that cannot handle the fault that would normally be shielded from receiving the fault because of the fault being handled previously. A difficulty with the system according to FIG. 2 is that the testing process does not consistently uncover fault handling problems that are buried deep in a call stack because the percentage fault specification may mean that a given process is repeatedly skipped. Similarly, one module may appropriately handle a fault, while masking another module's failure to handle the fault.
FIG. 3 shows an example of how a call stack may implement specified modules processes. Call stack 1 301 contain calls to various modules. Call stack 1 301 includes calls 304-310 that call modules 1 through 5 311-315 in the following order: 1, 3, 2, 1, 4, 1, and 5. A fault may be handled at call 304 while testing needed at calls 307 and 309 never occurs or occurs in an unpredictable pattern (because of the percentage fault chance described above).
A process for selectively initiating faults and for testing operating system functions is needed.